A problem that a storage sub-system returns imprecise data to a host system in reply to READ command causes not only loss of user data but also serious failure such as system failure. For this reason, in general, the storage sub-system avoids the problem that the imprecise data is returned to the host system by adding redundant data such as parity, ECC (Error Correcting Code) and CRC (Cyclic Redundancy Check) code to each data and checking the redundant data upon reading each data.
For example, a middle range or upper class RAID (Redundant Array of Inexpensive Disks) sub-system may add 8 to 16 bytes of redundant code to a sector of data of 512 bytes, which is a minimum unit of the user data upon writing (destaging) from a cache to a disk drive. Then, this redundant code is checked upon reading (staging) from the disk drive to the cache. In this way, error detection is performed in a data path after a backend interface of a RAID controller. Incidentally, in this case, the redundant code is data calculated uniquely out of the sector data of 512 bytes, and a code based on LRC (Longitudinal Redundancy Check), CRC (Cyclical Redundancy Check) or the like is generally used.
Meanwhile, when data are written into an actual disk drive, in some cases, a temporary abnormal event occurs during head seek by the drive due to external cause such as vibration. Data may be written into an LBA (Logical Block Address) different from the LBA specified by the WRITE request. However, in such a case, it sometimes occurs that an error of writing position cannot be detected by above described redundant codes at storage sub-system side.
This is specifically explained with reference to FIG. 8. As shown in the drawing, it is assumed that a sector data 1 (512 bytes) and LRC1, which is a redundant code corresponding to the sector data 1, are stored in LBA1, and a sector data 2 (512 bytes) and LRC2, which is a redundant code corresponding to the sector data 2, are stored in LBA2. Under this condition, the sector data 1 and the LRC1 are read from the LBA1 at procedure 1, and the LRC1 is checked at procedure 2. As a result, if the sector data 1 is consistent with the LRC1, the sector data 1 is modified at procedure 3, new LRC (LRC1′) is calculated at procedure 4, and corrected sector data 1′ and the LRC1′ are written into the LBA1 at procedure 5.
However, as shown in the drawing, it is assumed that data to be written into the LBA1 is written into the LBA2. In other words, the sector data 1 and the LRC1 which should originally be overwritten at procedure 5, remain stored in the LBA1.
Under this condition, if the sector data 1 and the LRC1 are read from the LBA1 at procedure 6 and the LRC1 is checked at procedure 7, it is judged that the sector data 1 is consistent with the LRC1.
That is, although imprecise data, which should originally not be returned, are returned at procedure 6, they cannot be detected at procedure 7. Moreover, under this condition, although not shown in the drawing, the sector data 1′ and the LRC1′ are assumed to be read from the LBA2. In this case too, data to be originally written into the LBA1 are read and furthermore, since the sector data 1′ is consistent with the LRC1′, it is impossible to detect the error of writing position.
In this way, a problem (hereinafter referred to as (the problem)) occurs that a storage sub-system returns imprecise data to a host system in reply to READ command.
Therefore, in some cases, for the problem, it is made possible to detect that the drive read data from a false address, by incorporating LBA information into a redundant code. By adopting this method, it becomes possible to detect an error for the case where there is a difference between the LBA to be written and the LBA actually written. Taking FIG. 8 as an example for explanation, it corresponds to the case where data is to be read from the LBA2 after procedure 5.
However, even by adopting this method, it is impossible to detect an error in the case where data are read from the LBA1 after procedure 5, since LBA1 information is included in the redundant code corresponding to the data which should have been overwritten at procedure 5 but were not actually overwritten. Therefore, there still remains a possibility that the problem occurs, even in a case where such a method is adopted.
As a prior art to detect an occurrence of the problem, there has been a method as described in the following. A disk drive unit or a host system stores write-history information within the data and at a different position within a disk when data are written, and these respectively stored write-history information are compared and verified when the data are read (for example, refer to Japanese Patent Laid-Open Number: Tokkai 2001-338468 (Pages 5 to 6, FIGS. 5 to 6)).
However, the invention of the Japanese Patent Laid-Open Number: Tokkai 2001-338468 (Pages 5 to 6, FIGS. 5 to 6) has the problem that a write-history is stored in an area which has no relation with a sector data and capacity of a drive is consumed. Furthermore, it also has the problem that since the write-history needs to be read differently from the sector data, it affects performance of reading.